2.1. The Role of The Applications In Rules

The rules in Tiny Firewall may target:

• particular applications
• groups of applications
• all applications.

Selecting 'All Application' allows to build gen eral rules for situation when the specific application is unknown or when there is a need to build a general rule. Selecting Group of applications or particular application allows to build more granular policies.

2.2. Application Definition

The application and dll may include following information:

• label
• description (friendly name - optional)
• MD5 (optional)
• Path (optional)
• Name (optional)

Label The rule refers the application by its label - name under which such application exists in the Application Repository. The label - name - of the application may be different from the actual name of the executable or .dll. The advantage of this is that you may give your applications friendly names or that you are not bound by the specific name of the executable or dll in case that it would change.

Description Most of the applications include the Description as a part of the information embedded in the executable. This information is automatically added by TF6 when used for the application definition.

MD5 Every file (including executables and dlls) has its unique signature - checksum - which is calculated based on its size and information embedded. It is considered as a fact that there are no two different applications with the identical MD5 signature. Thus MD5 serves as the unique identifier of the application or dll. One application may include multiple MD5 signatures.

Path Sometimes it is not possible or practical to define the application using MD5 checksum. The application may be defined by its position on the disk or network share. Event though this definition is not secure sometimes it may be practical to use it. 

2.3. Application Groups And Handling The Applications

The applications may be organized into groups. One application may be member of multiple groups. Groups may not be members of the groups.

System and User Groups

Tiny Firewall recognized applications running under user account and system account. This definition is reflected in the Application Repository. There are two types of the groups:

• User Groups (e.g Trusted, My Applications etc)
• System Groups (e.g. $SystemApps, $MySystem)

Note! Systemapplications groups ALWAYS bear '$' prefix.

Some applications may run under both types of accounts, some of them you don't know. If you are unsure or have application running under both accounts you may place it into both types of groups.

In order to understand all of this it is good to imagine the application activity at the endpoint:

When application starts it starts under one of two types of the accounts: either is starts as the user process or as a system process. There is nothing in between except of that certain applications (courtesy of Microsoft) may start as a system process and once they would identify a user continue as a user process.

When the application starts Tiny Firewall on the endpoint recognizes the application (or not if it is unknown) then it applies policy for unknown applications and if these are allowed to run then it applies policies applicable to 'All' applications) and from that point on it applies policies applicable to this application (based on its group membership etc).

In summary it is up to the administrator how complicated and granular his policies need to be.

4. Common Guidelines Applicable To All Types of Policies

4.2. Simple/Detail Rule Views

Each rule includes the description whi ch will appear in the 'Simple View'. This allows to build more human readable policies rather then pure tables with ports and protocols.

The rules in their views will be always sorted automatically according to the logic explained in other chapters. 

4.3. Automatic Sorting

In order to prevent user errors Tiny Firewall incorporate rule sorting mechanism which sorts rules based on the specific logic. Without this sorting mechanism it would be impossible to build the policies for more group memberships then just one.

The benefit is that no matter where and how you enter the rule you would always know that the rule will be applied correctly.

How to move rules where you want them...

Host Tiny Firewall incorporate several importance layers which allow to apply the rules where you need - still without manually shifting rules up and down in the rule list.

The importance layers are (by their importance from top to bottom):

• High Priority Preferred
• High Priority
• Medium Priority (All rules created on the endpoint - only if you allow)
• Low Priority Preferred
• Low Priority

As you can see you can apply four levels of the rule importance on the Tiny Firewall which should be sufficient for any needs. We recommend to keep the High Priority Preferred level for circumstances where you need to apply certain general overriding rule immediately (e.g. block all traffic, allow all traffic etc.)

4.4. Rule and Application Accounts

The endpoint firewall can distinguish and apply different policies based on the account under which the application run.

There are three options:

• User Account The rule will be applied for applications running under the user account
• System Account The rule will be applied for applications running under the system account. These are system services and processes
• All accounts The rule will be applied for all applications regardless the account the run under

Each choice has its use and it is up to the administrator to decide when to apply which. In general if you don't know the specific application and just want to block the port you will choose 'All Applications' running under 'All' accounts in the rule.

4.5. Enabled / Disabled Rules

You might need to disable created rules from various reasons. Tiny Firewall has the solution for this in a form of 'Disabled' parameter. Disabled parameter allows conveniently enable and disable rules previously created.

Note! Disabling the rule will cause it inactive for the entire organization and all filters associated with the rule. If you want to disable rule for particular combination of security memberships (filter) you must deselect such filter at the particular rule!

5.1. Sorting Network Security Rules

The benefit is that no matter where and how you enter the rule you would always know that the rule will be applied correctly.

Sort Order

The rules are sorted similar to how the Excel would sort the table - by Column A, then B, then C etc. In the network security module these columns and their order are:

• Priority (High, Low)
• Preferred (Preferred High > High > Preferred Low > Low)
• Application - by alphabet with ascending sort in this order: Application, Group, Any(*)
• Protocol - in this order: TCP, UDP, TCP/UDP, ICMP, Other
• Direction - in this order: in, out, in_out
• Local port - ascending in this order: single port, range
• Remote port - ascending in this order: single port, range
• Remote IP address - in this order - Single, Subnet, Any
• Time - Any has the lowest priority

5.2. Predefined Objects

Tiny Firewall allows to predefine network security objects for convenient use when building the policies. You can predefine following:

• IP addresses (including the combination of IP addresses and subnets)
• Protocols and ports (e.g HTTP is TCP, out, dest.port 80)
• Time Intervals (e.g. 'week days', 'weekends' etc.)

When building the policies you will be referring to these objects by their names which will appear in the options offered to fill in.

5.3. Creating Network Security Rules

When creating the network security rules you should consider your goal. Do you want to block the port in general or do you wan to block specific application? Either way Tiny Firewall offers wide array of options which may accomplish your security goal.

In general you should start with the simple rules allowing or blocking the ports for all applications and then - when you would become more comfortable - start to make your policies more granular.

When creating the rules you must consider following details (explained in different chapters):

• Rule enabled/disabled
• Type of the account the rule is targeting
• Filter - which entity the rule should apply to?
• Priority

6.1. Sorting System Security Rules

The benefit is that no matter where and how you enter the rule you would always know that the rule will be applied correctly.

Sort Order

• Priority (High > Normal (optional user rules) > Low)
• Preferred (Preferred High > High; Preferred Low > Low)
• Application (Application > group (alphabetically) > any app (*))
• Path (Subdirectory has higher priority then a rule for a parent folder. Rules with object directly specified are sorted ahead of rules with predefined objects (alphabetically sorted). Any (*) object has the lowest priority.
• Other criteria such as Time of Day (subset has priority over a longer time interval)  

Note: The Application Spawning it is sorted first by a child application and then by a parent application. The first priority has the application, then groups (alphabetically) and then Any (*).

6.2. Defining File Paths

Absolute paths: For local drives, use the drive letters (e.g. " C:\Folder1\Subfolder2\file.doc ") and for network mapped drives and shared folders locations use their UNC name (e.g. " server\some_share\some_folder\some_file.doc ").

Relative paths: in addition to absolute paths, also relative paths can be used, starting with variables:

• %SystemRoot% (Windows dir)
• %SystemDrive% (disk on which OS is installed)
• %ProgramFiles% (Program Files folder)
• %AllUsersProfile% (Documents and Settings\All Users)

Usage example: " %SystemRoot%\System32 ".

Some relative variables can expand into multiple directories:

• %UserProfile% (all dirs for user profiles)
• %RemovableDrives% (floppy disk drives)
• %CdRoms% (CD-ROM and DVD-ROM drives)
• %FixedDrives% (local disks)
• %LanDrives% (network mapped disks)

Paths can be also retrieved from registry, with the use of the following variables:

• %DirOnKeyValue% (syntax: %DirOnKeyValue%\(REGISTRY-KEY-PATH-HERE-STARTING-WITH-HKLM-OR-HKU)\\(ENTER-VALUE-NAME-OR-NULL-FOR-DEFAULT-VALUE)\\\(OPTIONAL-FILE-PATH-TO-APPEND) )
• %DirOnSubKeyValue% (syntax: %DirOnSubKeyValue%\(REGISTRY-KEY-PATH-HERE-STARTING-WITH-HKLM-OR-HKU-BEFORE-ENUMERATED-SUBKEY)\\(REMAINING-REGISTRY-PATH-AFTER-ENUMERATED-SUBKEY)\\(VALUE-NAME-OR-NULL-FOR-DEFAULT-VALUE)\\\(OPTIONAL-FILE-PATH-TO-APPEND) )
• %DirOnKeyEnumValue% (syntax: %DirOnKeyEnumValue%\(REGISTRY-KEY-PATH-HERE-STARTING-WITH-HKLM-OR-HKU)\\\(OPTIONAL-FILE-PATH-TO-APPEND) ) Note: enumerates all string values at the specified key and their data treats as file path

Note: DirOnXXX => do not use HKCU in rules = > it will be expanded with a service running under system account. %UserSpecific% gets special user specific folders go t from registry (syntax: %UserSpecific%\(FOLDER-TYPE-SUCH-AS-LOCALSETTINGS)\\\(OPTIONAL-PATH-TO-APPEND) )

Note: %UserSpecific% uses the HKU\(USER-SID)\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders and value name specified right after the %UserSpecific% variable to get the file path (usually under the Documents and Settings folder). The following value names are typical: AppData, Local AppData, Local Settings, Cache, Cookies. See your own registry for further options. %Root% => Get root of the specified folder (use with %DirOnKeyValue% ) => usage: %Root%\(OTHER-VARIABLE)

Wildcards: You can use ? and * wildcards in the file path segments (e.g. C:\Photos\?*\small\*.jpg ).

Note: ? means one character and * means zero characters or any characters. Use " ...\?*\... " instead of " ????????????????????????????????\*\... " to avoid undesired results. Do not use *.* since it gets only files or dirs containing "." in their name. To differentiate traverse access to particular folder, use two rules: " C:\SomeFolder\?* " and " C:\SomeFolder ".

6.3. Defining Registry Paths

Use HKCR, HKCU, HKLM and HKU shortcuts when defining paths to registry keys. Use two backslashes to separate a value name from the remaining registry path. Use "\\" for default value. (e.g. for value Version use " HKLM\Software\Microsoft\DirectX\\Version ").

Wildcards ? and * can be used to substitute one character or multiple characters.

Note: * means zero or any character, we recommend to use "?*" combination which means 'at least one character long'.

6.4. Defining Application Spawning and Dll Loading Objects

Applications and dlls are identified in rules by string ID, called Label, and are defined in Application Repository. This link is usually an executable or dll file name such as iexplore.exe.

Spawning and dll loading guard examples:

• Typical example of how to misuse known application is to start "cmd.exe del *.*" from a trojan application (without any control of the user). 
• Through spawning of explorer.exe ("explorer.exe someapp.exe") direct rule to spawn someapp.exe can be bypassed.
• dllhost.exe application running typically under system account is used as a surrogate process to host a COM dll. This way a code residing in a dll can gain unwanted privileges. 
• ntvdm.exe process hosts all 16bit applications (MS-DOS and 16bit Windows 3.1)
• Some applications are able to dynamically execute foreign code by loading a supplied dll and executing a predefined exported method in it. This is a case of rundll32.exe process as well as of all applications capable of containing plugins or ActiveX (such as Internet Explorer). Of course, knowing that behavior, malicious application can force its own dll to be executed by such trusted application thus hiding the malicious activity.
• Dll Loading Guard can be used to prevent loading of dlls by a particular application if they are changed.

6.5. Defining Services Objects

A Service is identified by its registry key name in the HKLM\System\CurrentControlSet\Services key (e.g. " Alerter ").

TF client contains the following services: UmxAgent (FW Event Manager), UmxCC (FW Communication Client), UmxCfg (FW Configuration Interpreter), UmxFwHlp (FW User-Mode Helper), UmxLU (FW Live Update) and UmxPol (FW Policy Manager).

6.6. Defining COM Objects

COM objects are identified by its CLSID (e.g. " 7EBFD170-E4FE-48C5-8E21-05D903BAAEEC} ")

Create In-Proc COM Server - It is very common for applications to use COM dlls such as ActiveX. The ActiveX is running in the security c ontext of an application, so this type of COM access cannot be used to gain more privileges than the application already has. However, special case are "container" applications such as Internet Explorer which are designed to dynamically load and host Acti veX controls. For example, in Internet Explorer, the ActiveX to load could be determined by HTML page. Similar to IE there are other programs that can dynamically load In-Proc COM Servers, such as the Windows scripting Host (wscript.exe) that can be directed to load COM module by a VB (.vbs) or JScript (.js) scripts. For these "container" applications we recommend not having them in the Trusted applications and rather running them under Default Security.

Create Out-Of-Process (Local) COM Servers - This is a way how one application can use (and also misuse) services of another application. This access is less common (but it still could be regular) and more dangerous, since it is a potential way how an application running under Default security can gain privi leges by controlling another - Trusted - application. Create Remote Server - this is similar to Create Out-Of-Process (Local) COM Servers but in this case the application to be controlled is running on a different computer. There is no reason why an unkno wn application should do that. It is recommended to Prevent such access in this case.

6.7. Defining Devices and Drivers

There are two ways how to identify devices:

Device name syntax: DRIVER-NAME}\DevN\*\{DEVICE-NAME} (e.g. " Tcpip\DevN\*\RawIp" or "*\DevN\*\RawIp " if the driver is unknown).

Link syntax (Plug and Play devices): Plug and play devices have the device name variable, so it is better to use the second syntax: DRIVER-NAME}\Link\{DEVICE-CLASS}\{DEVICE-LINK}DEVICE-LINK} (e.g. "*\Link\Modem\*" or "Disk\Link\*\usbstor*" )

• DRIVER-NAME} DRIVER-NAME}is the registry key name in the HKLM\System\CurrentControlSet\Services key (e.g. "Tcpip")
• DEVICE-NAME}  DEVICE-NAME}is the name of the device in the \Device namespace (e.g. for Device\Parallel0 you use " Parallel0 ").
• DEVICE-CLASS} - The most common device classes {DEVICE-CLASS} are System, MEDIA, USB, Image, Net, Infrared, HIDClass, Processor, Ports, Keyboard, Battery, 1394, Display, Volume, FloppyDisk, CDROM, DiskDrive, Mouse, SCSIAdapter, Modem.
• DEVICE-LINK is the device link used to identify PNP devices over boots. It is similar to an entry in registry, which can be found in the HKLM\System\CurrentControlSet\Control\DeviceClasses key (e.g. IDE#CdRomTEAC_CD-W28E____________________________2.1A____#5&35c6ca11&0&0.0.0#{1186654d-47b8-48b9-beb9-7df113ae3c67})

Wildcards ? and * can be used in links, device and driver names, so *CdRomTEAC* can do the job for the mentioned ugly DEVICE-LINK} DEVICE-LINK}.

Note: Device rules are sorted by path elements from left to right, * has the lowest significance.

6.8. Defining System Privileges

• Forced Process or Thread Termination - prevents the specified application to terminate other processes.
• System Shutdown - restricts the application to shutdown or restart the computer.
• Set Object Security - prevents the application to change Windows native (per user based) Access Control Li st (ACL) for objects such as files on NTFS drives, registry, services etc.
• Inject code - prevents the specified application to inject code into other processes. " SafeToInjectDllGroup " global property defines those dlls, which can bypass this restriction. By default, this global property points to " SafeDlls " dll group. Note: There are three standard ways how to inject code into another process, using global hooks, creating thread in the target process and behaving as a debugger of the target application. The first two are guarded here and the third is protected by the Acquire System Privileges access. In addition to that,  AppInit_Dlls registry value can be used to inject a specified dll into other processes (it is protected by the registry guard).
• Acquire System Privileges - prevents an application to acquire specific system privileges, which can be misused to gain unwanted access to the system. Those privileges are:
• SeAssignPrimaryTokenPrivilege - Replace a process level token
• SeBackupPrivilege - Backup files and directories
• SeDebugPrivilege - Debug programs
• SeIncreaseQuotaPrivilege - Adjust memory quotas for a process
• SeTchPrivilege - Act as part of the operating system
• Clipboard Access - the specified application cannot use clipboard for both copy and paste.

6.9. Defining Global Properties

The following global properties can be set:

Disable/Enable System Security Module Audit (SBXChangeSecurityAL) - Audit Level of the notification about disable/enable System Security module on client.

Start Process Audit (StartProcessAL) - Audit Level of the notification about a process start. Note: It must be set to Monitor in order to be able on the server to add unknown applications to the Application Repository.

End Process Audit (EndProcessAL) - Audit Level of the notification about a process end.

Unknown Application Start (UnkAppStartDlg) - Handling of unknown applications. Can be set to: No Special Action - when unknown application (does not exist in the Application Repository) starts, no special actions is done - rules with the "*" in the application column apply Show Options Dlg to User - displays Alert dialog to the user with an optional enrollment into the client specific database (applications in the client database have lower priority then applications in the policy from the server if conflict arises) Kill the Application - kills the unknown application unconditionally

Unknown Application Start from System Application (UnkSysAppStartDlg) - Handling of unknown system applications. Similar to Unknown Application Start, but valid only when parent application is a system application (e.g. when a particular new process is started from a service).

Dll Group to Bypass Inject Code Restrictions (SafeToInjectDllGroup) - Dll group which bypasses the Inject Code restrictions. Contains string name of an existing dll group in the Application Repository. See System Privileges for more details.

6.10. Defining Guards

To use only some features of System Security, you can turn OFF particular guards. You should do it by modifying settings for the "*" application.

For all system applications ("*" with the "S" flag set) we recommend to leave ON spawning and device guards only, unless you have properly filled $TrustedSystemApps group. A too restricted rule applied accidentally to core operating system services (they fall into the "S" - system applications) may cause problems during the system boot.

You can also adjust guards for a specific application or an application group.

If a particular guard is OFF (e.g File guard), then all rules for this object type (all file rules in this case) are bypassed for the specified application.

7.1. About Network Intrusion Detection Policies

Tiny Firewall incorporates the support for SNORT IDS databases. SNORT is an open standard Intrusion Detection format. More information about SNORT is at www.snort.org.

Tiny Firewall allows full customization of SNORT rules. At present time from the security perspective in order to protect the integrity of the IDS database Tiny Firewall interface does not allow to edit the SNORT signatures. The signatures may be changed manually through the editing of XML database. The support for UI based editing of SNORT signatures is planed in the near future.

Tiny Firewa ll recognizes two types of IDS rules - monitoring and preventing rules. While monitoring rules incorporate asynchronous cache mechanism and do not represent a threat as far as the speed of the processing it is very important to carefully consider the depl oyment of Preventing rules. Preventing rules inspect the traffic in real time and the speed of processing directly affects the endpoint. Therefore it is important to plan on IPS rules carefully and use only prevention rules which are necessary.

7.2. Adjusting IDS/IPS Rules

IDS/IPS rules may be modified based on:

• direction
• remote IP address
• remote port
• local port
• protocol

In order to preserve the integrity of IDS database Tiny Firewall does not allow to modify the signatures.

Remote IP addresses may only be modified using predefined IP address objects.